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Status of This Memo 


This memo defines an Experimental Protocol for the Internet 
community. It does not specify an Internet standard of any kind. 
Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 
Abstract 


Discussion in the community has begun to question whether RFC 3683 
and RFC 3934 provide the appropriate flexibility for managing 
Internet Engineering Task Force (IETF) mailing lists. This document 
is an RFC 3933 experiment designed to allow the community to 
experiment with a broader set of tools for mailing list management 
while trying to determine what the long-term guidelines should be. 
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1. Introduction 


As discussed in RFC 3683, the IETF needs to have rules of conduct to 
limit disruptive or abusive behavior while permitting a fair and open 
forum for the discussion of Internet standardization. The IETF has a 
long and complicated history of rules for managing conduct on its 
mailing lists. 
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RFC 2418 [RFC2418] permitted individuals to be blocked from posting 
to a mailing list: "As a last resort and after explicit warnings, the 
Area Director, with the approval of the IESG, may request that the 
mailing list maintainer block the ability of the offending individual 
to post to the mailing list." RFC 2418 also allowed other forms of 
mailing list control to be applied with the approval of the area 
director and Internet Engineering Steering Group (IESG). However, 
RFC 2418 applied only to working group mailing lists. 


The IETF discussion list charter [RFC3005] provides guidelines for 
ietf@ietf.org. These guidelines provide more flexibility than RFC 
2418. "The IETF Chair, the IETF Executive Director, or a sergeant- 
at-arms appointed by the Chair is empowered to restrict posting by a 
person, or of a thread, when the content is inappropriate and 
represents a pattern of abuse. They are encouraged to take into 
account the overall nature of the postings by an individual and 
whether particular postings are an aberration or typical. Complaints 
regarding their decisions should be referred to the IAB." In 
particular it appears that these decisions do not follow the normal 
appeals path outlined in RFC 2026 [RFC2026]. 


RFC 3683 [RFC3683] provides a procedure for banning named individuals 
from posting to an IETF mailing list for at least one year. However 
once such a ban is put in place for one mailing list, the individuals 
responsible for other IETF mailing lists can unilaterally remove the 
posting rights of that individual. 


RFC 3934 [RFC3934] amends RFC 2418 and grants the working group chair 
the ability to suspend a member’s posting rights for 30 days. 
However, it appears to remove the ability of the AD and IESG to 


approve longer suspensions or alternative procedures: "Other methods 
of mailing list control, including longer suspensions, must be 
carried out in accordance with other IETF-approved procedures." An 


argument could be made that the amendment was not intended to remove 
the already-approved procedures in RFC 2418, although a perhaps 
stronger argument can be made that the actual textual changes have 
the effect of removing these procedures. 


The IESG has issued a statement on mailing list management [IESGLIST] 
that allows working group mailing lists to be moderated. Under this 
procedure, specific off-topic postings could be discarded. However, 
this procedure does not allow the posting rights of an individual to 
be suspended; it simply allows the list as a whole to be moderated. 


The IESG issued a statement on disruptive postings [IESGDISRUPT] 
This statement applies procedures similar to RFC 3934 and to the 
statement on moderated lists to non-working group lists. 
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The result of these guidelines is that there is a large gap between 
the levels of sanction that can be applied. An individual can be 
suspended from a working group list easily for 30 days. However, the 
only option available to the IESG that permits a longer suspension 
for any list besides ietf@ietf.org is the ability to suspend an 
individual for an indefinite time period from one list. This 
suspension can expand to any IETF list without community or IESG 
involvement. This memo is an RFC 3933 [RFC3933] experiment to 
provide the IESG with the ability to create additional mechanisms to 
manage IETF mailing lists while the community decides what mailing 
list guidelines are appropriate. In particular, this experiment 
allows the IESG to create a level of sanction between RFC 3934 and 
RFC 3683 for working group lists and to create sanctions other than 
RFC 3683 for non-working group lists. The goal of this experiment is 
to improve the functioning of IETF mailing lists while keeping the 
process open and fair. This experiment is successful if it gives the 
community useful input on how to design a mailing list management 
process. It is not expected that this experiment will be adopted in 
its current form as a permanent Best Current Practice (BCP). 


2. Requirements notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Definition of IETF Mailing List 


This experiment applies to all IETF mailing lists, including those 
not associated with a working group. The definition of a working 
group list is clear, but the definition of an IETF mailing list 
comprehensive enough to include all IETF mailing lists is not 
obvious. For the purpose of this experiment, an IETF mailing list is 
defined as follows. 


An "IETF mailing list" is defined as the IETF list itself, any 
mailing list operated to further the work of a current IETF Working 
Group (WG), any mailing list created for WG use but retained for 
ongoing discussion after that WG was shut down, any mailing list 
created in support of an IETF-specified procedure (including mailing 
lists whose purpose is the discussion of registration actions), and 
any mailing list hosted on any site or system operated by the IASA or 
otherwise on behalf of the IETF. Mailing lists listed at 
https://datatracker.ietf.org/public/nwg_list.cgi are explicitly 
included in this definition. 
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4. 


The Experiment 


This experiment runs for a period of 18 months. During the 
experiment period, the IESG MAY approve other methods of mailing list 
control besides those outlined in RFC 3683 and RFC 3934 to be used on 
a specified set of IETF mailing lists. Such methods include but are 
not limited to suspending the posting rights of an individual beyond 
30 days on those lists. Under such procedures the IESG may delegate 
the authority to perform longer-term suspensions of specific 
individuals on specific mailing lists. 


The procedures of this memo MUST NOT be used to suspend the posting 
rights of an individual beyond the period of the experiment. The 
procedures of this memo MUST NOT be used to limit an individual’s 
ability to read the contents of a mailing list. 


The IESG MUST inform the community in a public statement of any 
procedures for mailing list management approved under this 
experiment. Such a statement should include the description of the 
procedure and the description of mailing lists to which it applies or 
an indication that it applies to all IETF mailing lists. The IESG 
MUST make a public announcement of a new procedure at least 14 days 
prior to the procedure taking effect. Although the community is 
encouraged to comment on any IESG action, community consensus is not 
required to approve such a procedure. All currently active 
procedures under this experiment MUST be made public in an 
appropriate, easy-to-find location. 


Sanctions made under this memo may be appealed using the procedures 
outlined in [RFC2026]. 


How the Experiment May Be Used (Informative) 


The IESG could approve a procedure allowing it to suspend an 
individual from one or more mailing lists for a fixed period of time 
greater than 30 days. 


Also, the IESG could delegate this power. Two types of delegation 
are envisioned. In the first, the IESG has a procedure that allows 
it to suspend a named individual from a list and to grant the 
managers of that list the delegated authority to continue to apply 
longer suspensions if disruptive behavior continues. In the second, 
the IESG approves a procedure that specifies a set of lists and 
allows managers of those lists to take action unilaterally after an 
initial suspension in a manner similar to RFC 3683. 
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6. Security Considerations 


This document describes a modification to the IETF process for 
managing mailing list discussions. It has no security 


considerations. 
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